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(57) ABSTRACT 

A plurality of users communicate in a plurality of real-time 
text conversations (e.g., "chat sessions") in a client-server 
message processing environment using messages including 
a conversation index, a conversation-initiator ID and a list of 
message recipients. Each conversation is maintained at 
client terminals in an individual window. Dropping and 
controlled adding of conversation participants is attended by 
message updates to other participants. Alternative peer-to- 
peer message handling reduces the processing burden on 
servers while allowing clients to perform control and display 
functions. Voice or other non-text messages are also com- 
municated using described techniques. 

15 Claims, 6 Drawing Sheets 
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SYSTEM AND METHOD FOR MULTIPLE added in similar fashion. The server provides a separate chat 

ASYNCHRONOUS TEXT CHAT room or channel not accessible by anyone not invited by 

CONVERSATIONS those in the established private chat room. 

pipt n np tut: T\rv/PMTir\\r Instant Messaging (IM) allows a user to launch a message 

FIELD OF THE INVENTION 5 to anomer user. Variants of IM permit a notice to be sent to 

The present invention relates generally to the field of others (e.g., those on a "buddy list" ) when a particular user 

messaging systems and methods. More particularly, the I°g s on t0 a server, even without joining a chat or other 

present invention relates, in one aspect, to methods and two-or-more-person conversation. Users announce their 

systems for maintaining multiple simultaneous asynchro- availability to receive messages by electing options or 

nous text (or other) conversations. Still more particularly, 10 submitting system parameters in advance. The sender of an 

aspects of the present invention relate to systems and instant message determines who will receive the message, 

methods for establishing and maintaining multiple simulta- While the foregoing and other features of e-mail, chat and 

neous asynchronous message sessions between overlapping instant messaging have proven very useful in a number of 

or non-overlapping sets of users in data communications contexts, these systems suffer from a number of real time 

contexts, such as Internet chat sessions. 15 limitations. For example, current chat environments limit 

users to participation in only one multiple-party (three or 

BACKGROUND OF THE INVENTION more participant) real-time chat room at a time. Users may 

The Internet and many on-line information services pro- participate in more than one conversation in real time, if 

vide electronic mail (e-mail), conferencing and chat mese are two-way conversations. Likewise, a user may 

services, and the ability to access remote computers for pursue multiple conversations (strings of messages) with 

sending and retrieving files. E-mail, perhaps the most widely multiple users, but only over an elapsed time period using 

used of Internet and on-line service applications, has an multiple windows for conversation events, participation, and 

(often desirable) inherent "off-line" time delay characteris- display. 

UC ; ^ , _ , x 25 SUMMARY OF THE INVENTION 

Internet Relay Chat (IRC) or, simply "chat" provides 
informal communications among users of data network Limitations of the prior art are overcome and a technical 
facilities. Chat allows two or more users to converse by advance is made in accordance with the present invention 
exchanging text messages, typically through a "channel" or described in illustrative embodiments herein, 
virtual "chat room" maintained on one or more chat servers 30 In accordance with one aspect of the present invention, a 
and accessed via an on-line service or using general purpose user maintains multiple simultaneous real-time chat sessions 
chat "client" software executing at a user terminal, work- with a plurality of other participants using a single client 
station or personal computer. Only chat "participants" con- residing on a personal computer, workstation or terminal 
nected (typically through a telephone line modem) to the (collectively, "terminal"). Advantageously, each of the con- 
on-line service or other chat environment provided by one or 35 versations is presented in a separate window on the terminal, 
more chat servers, can take part in the chat. Chat room and the user can select a window for text input in the usual 
"conversations" are displayed as text in a chat room window way. 

on a participant's display screen, usually accompanied by a In accordance with an illustrative embodiment, a tech- 
list of chat participants. The text displayed at a participant's nique for labeling and addressing messages is introduced 
terminal usually includes a history of the conversation from ^ and applied in a data network with a technique for presenting 
the time that the viewing participant joined the chat room. conversation events, messages, and history. These and other 
Entering particular chat rooms is typically effected using a features of illustrative embodiments permit dynamic cre- 
list or menu of currently available chat rooms. Exiting a chat ation of multiple simultaneous asynchronous conversations, 
room is usually as simple as closing the chat window. each among multiple users, in a distributed manner— all in 
Extensions of the basic chat model of communications 45 real time. Participants in component conversations may 
permit use of voice (or other audio), video and other change over the life of the conversation and the conversa- 
message content. tions will include overlapping sets of users. 

Chat Rooms (including private chat rooms, described Participants send messages in the context of a particular 

below) are established on chat servers in advance of text conversation. In accordance with an illustrative system 

conversations, and allow many users to communicate via 50 embodiment, these conversations and communications 

messages. Any user may elect to join a chat room (become events (e.g., adding a participant, removing a participant) 

a participant), subject to prior subscription or registration among multiple users are tracked in a completely distributed 

procedures imposed by the on-line service provider or manner and in real time. The conversation data, including 

operator of the chat servers). Many versions of chat client events, messages, and history, is presented to the user in an 

software, with varying functionality and communications 55 organizational structure that uniquely identifies the conver- 

protocols, are widely available on the Internet for download. sation. 

Participants in a chat room receive all messages sent to the While participants in several simultaneous real-time con- 

chat room and can decide to contribute input messages versations may be overlapping to various extents, in one 

according to personal preference. class of embodiments the set of messages sent to participants 

Private chat rooms are set up by a participant seeking to 60 in one or more of the conversations is mutually exclusive of 

have private text communications with a selected one or the set of messages sent to participants in one or more other 

more other participants in an existing chat. Toward this end, conversations. A useful illustrative example is a session 

the initiating participant typically sends a "query" or similar including a negotiation between two (or more) principal 

message to another participant with whom the initiating negotiators, each of whom has background advisors. The 

participant wishes to privately communicate. A recipient of 65 respective advisors take part in "whisper conversations" 

this query agrees to take part in a private chat with the with their principals) that cannot be observed ("heard") by 

initiating user by responding to the message. Others may be the opposing negotiator or opposing advisors, or even others 
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on the same side of the negotiation. Side conversations, e.g., 
between opposing advisors seeking to resolve underlying 
technical or procedural points, can be pursued under the 
observation of other advisors and/or principals in separate 
chat windows. Advantageously, advisors on the same side 
can selectively pursue such side conversations as well. 

BRIEF DESCRIPTION OF THE DRAWING 

The above-summarized description of illustrative 
embodiments of the present invention will be more fully 
understood upon a consideration of the following detailed 
description and the attached drawing, wherein: 

FIG. 1 is an overall view of a data network in which 
embodiments of the present invention are used and prac- 
ticed. 

FIG. 2A shows an illustrative client-server message han- 
dling architecture for use with embodiments of the present 
invention. 

FIG. 2B shows an illustrative peer-to-peer message han- 
dling architecture for use with embodiments of the present 
invention 

FIG. 3 shows an illustrative chat initiation window for use 
by a message-initiating user at a client terminal. 

FIGS. 4A-C, 5A-C and 6A-C show illustrative views of 
windows at typical client terminals during various phases of 
establishing, maintaining and removing from conversations. 

FIG. 7 shows a terminal display with a plurality of 
simultaneous real-time multiple party message conversa- 
tions in respective windows. 

DETAILED DESCRIPTION 

Terminology 

It proves useful to introduce a set of terms as a basis for 
the detailed description given below. For this purpose the 
following terms and respective meanings will be applied: 
Session: all potential participants in on-line conversations. 
Thus, in the negotiation example mentioned above, all users 
on both sides are part of the session. In other cases the 
session may include a group of users such as those logged 
onto an on-line service or similar chat room, or included in 
a "buddy list" maintained by a user. 
Conversation: a string of messages among participants in a 
session, presented within a window at each participant's 
display. Non-participants in a conversation do not receive 
messages in a conversation, nor can non -participants send 
messages to participants in the context of the conversation. 
A conversation has a history that may be different for 
different participants. 

Message: information generated by a participant that is 
added to a conversation history. Also includes control infor- 
mation including conversation id and a list of participants in 
a conversation. 

Initiating Message: the first message in a conversation. 
Augmenting Message: a message that indicates a participant 
has been added to a conversation. 

Pruning Message: a message that indicates a participant has 
been removed from a conversation 
Illustrative System Overview 

FIG. 1 shows an illustrative data communications system 
150, such as the Internet with attendant access facilities, in 
which the present invention may be applied. Of course 
network 150 may be an on-line service network, or any other 
real-time message-handling network. In network 150 a rep- 
resentative plurality of personal computers, workstations, or 
terminals (collectively "terminals"), 105-/, i-l, 2, . . . , N are 
shown connected by way of telephone lines or other access 
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paths through a data network (illustratively, the Internet) 100 
to a server 110. N can be any positive integer, subject to 
transmission and processor capacity limitations. 
Server 110 is shown with dashed lines on its right to 

5 indicate that the server functions may be distributed over an 
arbitrary number of networked cooperating servers. Each 
terminal 105-/ is connected (through standard access 
facilities) to an associated server. In some cases all terminals 
will be associated with the same server, but more generally 

10 one or more terminals will be connected to each of a group 
of servers. In typical operation, the terminals 105-i execute 
client software for cooperating with server software running 
on a respective server 110 to enable chat functionalities. In 
one illustrative case, client and server software will be based 

is on well-known chat components such as mIRC client and 
server software by mIRC Co. Ltd. which is available on the 
Internet, e.g., at hup ://www. mire .co.uk, and from other 
distributors. 

Further information about well-known chat software and 

20 procedures is available from the Undernet User Committee 
web site at www.user-com.undernet.org/documents/. Of par- 
ticular note is Network Working Group Request for Com- 
ments: 1459, by J. Oikarinen and D. Reed, May, 1993, 
available at the Undernet web site. This latter document 

25 presents a version of the Internet Relay Chat (IRC) Protocol 
that has provided important bases for current chat imple- 
mentations. Other particular client/server implementations 
of various chat functionalities include several quIRC chat 
software modules. 

30 Standard chat methodologies, including those recited 
above, or used in other chat systems well known to the art, 
or described in documents well known in the art, are 
modified and extended in accordance with aspects of the 
present invention to realize desirable inventive functional- 

35 ities. Features and operations of illustrative systems, meth- 
ods and protocols for achieving advantages of the present 
invention will be described below. 
Message Handling Architectures and Protocols 
A principal mechanism for communicating messages and 

40 managing windows for viewing chat conversations in accor- 
dance with illustrative embodiments of the present invention 
is the well-known client-server architecture, as modified in 
the manner described below. FIG. 2A illustrates a simple 
client-server architecture for message handling in accor- 

45 dance with one class of embodiments of the present inven- 
tion. In FIG. 2A, a snapshot of activity among a sampling of 
network elements, messages are seen to be sent from one 
client (illustratively client 220) to a server 210. At server 210 
processing of the message is performed to effect control and 

50 distribution of messages in a conversation (to clients 230 
and 250, for example). At other times, clients such as 230, 
240 or 250 originate messages that are processed by server 
210 and forwarded, as appropriate, to other clients. In 
accordance with aspects of embodiments of the present 

55 inventive contributions, a client maintains a plurality of 
simultaneous plural -participant conversations. 

Alternatively, many of the message handling and window 
control operations used in embodiments of the present 
invention are advantageously accomplished using a peer-to- 

60 peer interconnection among clients. Such a system arrange- 
ment is shown in a simplified example in FIG. 2B, where 
clients 260, 270, 280 and 290 are shown selectively com- 
municating messages. Because a message format is used, in 
accordance with one aspect of the present invention, that 

65 always allows a receiving client to identify the chat conver- 
sation with which a message is associated, much of the 
routing and window control functionality can be left to the 
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client software at user terminals. Aspects and advantages of The ASCII message protocol conveniently used to 
such peer-to-peer interconnection will be discussed below. describe the messages exchanged between the client and the 
As with the presently modified client-server architecture, a server in many chat environments is adopted for the present 
client can maintain plural simultaneous conversations, each illustrative embodiments. Because many aspects of existing 
with a plurality of other participants. 5 c h a t message protocols will prove useful in employing the 
Initially, however, it will be assumed for illustration that prescnt invention, elements useful in introducing the above- 
a client-server architecture is used to permit clients to recited and other inventive features will be used in augment- 
exchange messages through one or more respective servers. i ng cx isting formats and protocols. In any event, it will be 
Each client is associated with a particular server, which understood that many particular message formats may be 
server may be shared among clients or co-located with a to adopted for use with the present inventive contributions, as 
designated client. Such a client-server arrangement can be circumstances may allow or dictate. To provide a common 
considered to be essentially a star configuration if intercon- illustrative format, it proves useful to employ the following 
nected servers, if any, are considered as one server. This message elements: 
latter condition will be assumed in discussions of client- 
server system organizations in the sequel. That is, it will be is 

assumed that all servers in a multi-server network will ( H eadi nl}+nl nl [Name: Value]* nl NX NL * 
maintain, or have ready access to, lists of participants and 

other message handling information maintained at servers to where NL (newline) is also represented as \n. A message is 

control the processes described below. Such exchange of therefore taken as complete when it has at least 

information between servers is commonplace in multi- 20 
server environments. 

In beginning a discussion of typical message handling [headi nl]+nl nl and an optional set of (name, value) pairs, 
operations in accordance with the present invention, it will 

be recognized that any message conversation has an initiator Some Example Messages 

and a set of participants. Further, any message has a sender 25 A sequence of messages will now be shown and discussed 

and a set of recipients that is a superset of the set of to illustrate aspects of chat methodology used in illustrative 

participants. In accordance with one aspect of some illus- embodiments of the present invention. In these example 

trative embodiments of the present invention, a message that messages, a two-line command sequence appears as, for 

includes a set of recipients that is a proper superset of the set example, 

of participants advantageously changes the set of partici- 30 2 

pants in the conversation to include all the recipients of the n. 

message. A message therefore includes an identification of The syntax and semantics for all instances of this useful, 

the existing participants in the conversation, and perhaps but arbitrary, command sequence will not be presented, but 

others being added by the message. me command function and results appear in the messages 

In accordance with illustrative embodiments of the 35 an( j associated discussion. Other particular commands and 

present invention, characteristics desirably included in any command sequences will prove useful in particular contexts, 

message from a message-originating user are message ele- a s will be apparent to those skilled in the art. 

raents identifying (i) the originating user, (ii) all recipients of For purposes of the illustrative example messages, it is 

the message, and (iii) a conversation index. assumed that the session involves users Dawn, Mike and 

Thus, each user in a conversation has a unique identifier 40 rj ave> initially, Dawn is preparing to initiate a conversation 
(unique across the session, at least) associated with the user. w i t h Mike. The following illustrative initiate chat message 
This user identifier may be assigned specifically for the reflects Dawn's use of her client software from her terminal 
session or may be persistently associated with the user. to indicate that she would like to initiate a chat The message 
Examples include an e-mail address or an Internet Protocol ^ sent f r0 m her client to a communications server. 
(IP) address, but nicknames are common in chat contexts. 45 Messaee-Beein 
Also, as noted, it proves advantageous to cause all conver- 
sations initiated by a sender have a unique conversation Session ld> 
index. The combination of sender's ID and conversation 2 
index are advantageously used by all recipients of a message 11 

to determine the conversation with which the message is 50 ChatRoomName:<User Specified Room Name> 

associated. The system will have unique names for each ui D:<User > s unique Id for the Session> 

conversations generated by the initiators and, as is usual for ¥ t ¥TW . . 

chat rooms, unique names for each participant visible to UIDNameList:<comma separated list of participants' 

each participant. UID for this 

In one illustrative embodiment, any participant can add a 55 Chat Session excluding the Chat room Creator> 

new participant at any point in the conversation. This Message-End 

conversation event advantageously triggers a message to all Information for this message is conveniently entered in a 

other participants, causing their view to be updated. Any window created by the client software at Dawn's terminal, 

participant may choose to remove himself or herself from a e.g., in response to selecting an "Initiate Chat" button from 

conversation. As in the case of adding a participant, this 60 a menu or the like presented by an opening (or other) screen 

event conveniently triggers a view-updating message to all on Dawn's client. An example window of this type is shown 

participants. These and other typical message characteristics in FIG. 3. Because the client software is aware of the 

and operations will now be illustrated in an illustrative initiator's (Dawn's) User ID, it is not necessary for her to 

example involving the initiation of a chat room, the subse- explicitly enter this UID. 

quent use of the chat room to broadcast to participants, and 65 When the initiate chat message given above is received at 

the removal of participants from the chat room. the server, it is parsed and processed in accordance with the 

Message Formats following illustrative pseudo code: 
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Code-Begin 

If (ChatRoomName+Creator-Id already present in the list of Chat Rooms) 
{ 

send the following error response for the Chat Room 
Creation Request: 
Message- Begin 
<Scssion Id> 
2 
12 

crrorCode:6 errorstring: Duplicate Chat Room 

ChatRoomName: <ChatRoomName+Creator-Id> UID:<User*s unique Id 
for the Session> UIDLiflt:<comma separated list of participants' UID for 
this Chat Session excluding the Chat room Creator) 

Message-End 

} 

else 
{ 

Add the Chat Room to the list of active Chat Rooms; pair; Extract the 
List of participants from the NickNameList N/V pair; 

Send the following Response Message to the Chat Room Creator and all 
the participants of the chat room: 
Message-Begin <Session Id> 
2 

12 

ChatRoomName:<ChatRoomNamc+Crcator-Id> UID:<User's unique Id for the 
Session> UIDUst:<rcomma separated list of participants' UID for this Chat 
Session excluding the Chat room Creator) 
Message- End 

When the message is received by the client software residing on conversation 
participants* terminals, the following processing illustratively transpires: 
// processing by the Creator 
if (creation of chat room is successful) 
{ 

if (there is no other chat room with the same name exist) 
{ 

display a chat room with just the room came 

else 
{ 

display a chat room with the room + creator's id 

modify the name of the other chat room with the same name to 

room name + creator's id (this is creator of this room) 

} 

} 

else 

display an cnor message informing the error 

} 

// processing by rest of the participants 

if (there is do other chat room with the same name exist) 

{ 

display a chat room with just the room name 

} 

else 
{ 

display a chat room with the room + creator's id 
modify the name of the other chat room which has the same 
name to room name + creator's id (this is creator of this room) 

Note that the participants do not ordinarily receive an error message for creation 

of a chat room. 



FIGS. 4A-C illustrate a continuation of the foregoing 
example. There, Dawn and Mike view their Conversation in 55 
respective windows. Mike is preparing to send a message to 
Dawn indicating that he is about to add Dave to the chat. In 
accordance with one illustrative embodiment of the present 



invention, any participant in a chat room can add a new 
participant to that chat room. To effect the desired addition 
the following message is sent by a client, such as the client 
at Mike's terminal, to the Server: 



Message- Begin 
<Session Id> 
2 
13 

ChatRoomName : <ChatRoomName-t-CreatoMd> 
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UID:<uset issuing the request> 

UIDList:<comma separated list of participants' UID to be added to this chat 
room> 

Message- End 

Upon receiving the above message, the server performs the following processing: 
Code-Begin 

If (ChatRoomName+Creator-Id does not exist) 
{ 

send the following error response for the Chat Room Creation Request: 

Message- Begin 

<Session Id> 

2 

14 

errorCode:7 

errorString: Invalid chatroomname 
CliatRoornName:<rChatRootnName+Creator-Id> 
Message- End 

} 

else if (user issuing the request is not a participant of this chat room) 

send the following error respoase for the Chat Room Creation Request: 

Message -Begin <Sesaion Id> 

2 

14 

errorCodc: 8 

errorString: Participant does not exist in the room 
ChatRoo m Name : <ChatRoo mNa me+Crea tor- Id> 
Message -End 

} 

else 

extract the list of participants from the message, add them to the 

list of participants in the room. Broadcast the following message 

to all the participants in the room. 

Message- Begin 

<Session Id> 

2 

14 

ChatRoomName:<ChatRoo[nName+Creator-Id> 
UID:<user who issued the add request > 

UID List :<comma separated list of UIDs for participants who have been 
added to this chat room> 
Message- End 

Upon receiving the above message the client software residing on conversation 
participants' terminals performs the following: 

// Processing by the user who issued the add if adding the participant 

was successful 

{ 

add this participant to list of active users in the corresponding 
chat room 
} 

//processing by the client for the participant who was added 
if (there is no other chat room with the same name exist) 
{ 

display a chat room with just the room name 

else 

display a chat room with the room + creator's id 

modify the name of the other chat room which has the same 

name to room name + creator's id (this is creator of this room) 

} 

//processing by rest of the participants add this participant to list of 
active users in that corresponding chat room. 



FIGS. 5A-C show screens at the terminals of Dawn, 
Mike, and Dave for viewing of their conversation after Dave 
has been added. 

Broadcasting a Message in a Chat Room 

Any Participant in a chat room can broadcast a message 
to all participants in that chat room. The following illustrates 
a typical process in which a message is sent by a client to the 
server: 
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Mess age- Begin 
<Session Id> 
2 
19 

ChatRoomName : <ChatRoomNamc+Crcator-Id> 
UID:<user broadcasting the message > 
Message :<message to be broadcast 
Message-End 

Upon receipt of the above message the receiving server performs the following: 
Code-Begin 

If (ChatRoomName+Creator-Id does not exist) 
{ 

send the following error response for the Chat Room Creation Request: 
Message- Begin 
^Session Id;> 
2 

20 

errorCode:7 

errorString:Invalid chatroomname 
ChatRoomNamc:<ChatRoomName+Crcator-Id> 
Message -End 

} 

else if (user issuing the request is not a participant of this chat room) 
{ 

send the following error response for the Chat Room Creation Request: 
Mess age- Begin 
<Session Id> 
2 

20 

errorCode:8 errorString:Participant does not exist in the room 

ChatRoomName:<ChatRoomName+Creator-ld> 

Message- End 

} 

else 
{ 

get the chat room identifier, broadcast the following message to all 

the participants. 
<Session Id> 
2 
20 

ChatRoomName:<ChatRoomName+Creator-Id> 
UID:<user broadcasting the message* 
Message :<message to be broadcast 
Message- End 



Upon receiving the above message the client software 
residing on conversation participants' terminals performs 
the following processing: 

// processing by all participants in the chat room display 
the message received from that user who had sent it. 
Participant Leaving a Chat Room 

FIGS. 6A-C show screens at the terminals of Dawn and 
Dave for viewing of their conversation after Mike has 



removed. Mike's conversation window is shown as closed in 
FIG. 6B. A participant in a chat room session can leave a 
chat room at any time. When a participant desires to leave 
a chat room the client for that participant recognizes the 
user's wish to be removed (as signaled, e.g., by a mouse 
click or the like on a button) and sends the following 
message to the Server: 



Message- Begin 
<Session Id> 
2 
23 

ChatRoomName:<ChatRoomNamc+Creator-Id> 
UID:<user who is leaving the room> 
Message- End 

Upon receiving the above message the server platforms the following processing: 
Code-Begin 

If (ChatRoomName+CreatoMd does not exist) 
{ 

send the following error response for the Chat Room Creation Request: 
Message- Begin 
cSession ld> 
2 
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24 

errorCode:7 

crrorString:Invalid chalroornnamc 
ChatRoomNamc:<ChatRoomName+Creator-Id> 
Mess age- End 

} 

else if (user issuing the request is not a participant of this chat room) 

send the following error response for the Chat Room Creation Request: 

Mess age- Begin 

<Session Id> 

2 

24 

errorCode:8 

errorString: Participant docs not exist in the room 
ChatRoomName:<ChatRoomName+Creator-Id> 
Message- End 

} 

else 
{ 

broadcast the following message to all of the participants in the session. 

<Scssion Id> 

2 

24 

Cha tRoo mName : <Cha tRoom Name+Crcator- Id> 
UID:<oiser who is leaving the room> 
Message- End 



Now, remove the participant from the list of participants 
in that session, so that any other messages for this chat room 
will not be broadcast to that participant. 30 

Note that a mechanism is present to ensure that a request 
to leave a chat room from a participant has to be confirmed 
and that only that concerned participant is issuing the 
request. This ensures that not any participant in that chat 
room can drop anybody else. 35 

If the number of participants in the session is zero, then 
the chat room is destroyed. 

> 

Upon receiving the above message processing at the client 
software residing on conversation participants' terminals 40 
proceeds as follows: 

// processing by the participant who attempted to leave if 
the attempt to leave the chat room was successful, 
destroy the chat room display. 

// processing by rest of the participants 45 

If a participant has left the chat room successfully, remove 
this participant from the active list of participants in 
that chat room. 
Multiple Chat Rooms on a Single Client 

From the foregoing examples of the creation and process- 50 
ing of chat messages in accordance with embodiments of the 
present invention, it becomes clear that an initiator of a first 
chat conversation can originate a second or subsequent 
conversation. Through the expedient of choosing a distinct 
conversation index upon initiating a subsequent 55 
conversation, messages for different conversations can be 
readily separated. Likewise, participants in the respective 
conversations are initially chosen by the initiator and can be 
augmented by the initiator and, illustratively, others after 
they become participants. 60 

Similarly, other session users can become initiators and 
designate other respective recipient lists (members of which 
become participants). An initiator of a first conversation can 
readily become a participant in a conversation initiated by 
another user, merely by being identified in a recipient list by 65 
an already existing participant. FIG. 7 shows a display 700 
at a terminal for a user (here the above-mentioned Dawn) 



including separate windows 710 and 720. Window 710, in 
turn, is seen to display messages in a conversation between 
Dawn, Mike and Dave, as in a preceding example. Window 
720, on the other hand, reflects an ongoing conversation 
between Dawn, Tom and Dick. While Dawn provides the 
only conversation participation overlap between the two 
conversations, she (or one of the other participants in one of 
the conversations in windows 710 or 720) can add another 
participant from one of the conversations to the other 
conversation. Of course, any of the participants can add 
additional users who are not present participants of either 
conversation. Likewise, Dawn or any of the other partici- 
pants can initiate a new conversation through the mechanism 
described above. 

In other particular embodiments, additional conditions or 
controls on adding new participants are readily effected. For 
example, in a client-server message handling system, an 
augmenting message can be tested against a list of autho- 
rized augments, including, in some cases, only the conver- 
sation initiator. When a submitted augmenting message is 
received at a server and found not to be originated by an 
authorized augmentor-participant, the proposed augmenting 
is refused; the newly proposed addition to the participant list 
is rejected. Other particular policies can be imposed to 
reflect the nature of the conversations and participants. For 
example, additions to purely social chat contexts can be 
considerably relaxed as compared with conversations 
involving a need for privacy or secrecy. 

Each simultaneous, real-time, multiple-participant 
(including three-or-more-participant) conversation is 
reflected at a user's terminal by a separate window. The 
respective conversation windows can be overlapped, and are 
otherwise manipulated in well-known ways (i.e., in respect 
of sizing, backgrounding, etc.) by standard window- 
handling client software. 

The overall session population can likewise be a factor in 
administering admission policies. Thus, members of this 
overall user group may have already been prescreened, as by 
inclusion on one or more "buddy lists" or have been pre- 
selected by participation in side message or voice conver- 
sations leading to invitations to join the overall (or a 
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particular identified conversation) session. Even with such 
pre -screening, however, it proves useful to impose condi- 
tions or controls on entry by potential participants in par- 
ticular conversations. Thus the negotiation example given 
above illustrates the possible need for controls of varying 
restrictive ness. In some cases, passwords or other keywords 
may be required before an augmentation message will be 
honored. Such additional control functions are easily added 
in message dialogues between clients and respective servers 
through analysis of incoming messages, including augment- 
ing messages, for the presence of additional descriptive or 
authorization information. 

While the preceding detailed description has used the 
client-server model of message processing for purposes of 
discussion, it will be apparent to those skilled in the art that 
the message analysis and establishment of lists and controls 
for particular conversations may be effected primarily at 
receiving clients rather than at servers. Thus, for example, 
the peer-to-peer architecture of FIG. 2B may be used. 

It will be appreciated from the foregoing discussion and 
examples that when a message is launched in the context of 
an existing or initiated chat conversation that contains the 
conversation ID, the message originator's ID and the iden- 
tification of the intended recipients, the latter information 
can be used by network routers (including respective 
servers) to route the messages to the terminal(s) of the 
indicated addressees. 

The receiving local clients in the peer-to-peer system 
organization of FIG. 2B then use the conversation ID and 
originator ID to identify the conversation and direct message 
content and control information to local client processing. 
Thus, for example, receipt at a receiving client of a message 
with a new conversation ID and originator ID will typically 
cause that client to establish a new message window, 
provided, of course, that any pre-agreed security or interest 
criteria are satisfied to the satisfaction of the receiving client. 
Then, when future messages having the same conversation 
ID and originator ID are received they are directed by the 
receiving client to the associated window and related control 
processes — all at the client. It will be appreciated by those 
skilled in the art that use of the peer-to-peer system orga- 
nization with message handling of the type described above 
in the examples will in many cases significantly reduce the 
processing burden on servers and permit improved real-time 
performance. That is, the servers act primarily as message 
forwarding nodes in peer-to-peer network operation. 
Additionally, particular users will have more immediate 
control over execution of local client software for purposes 
of introducing admission controls, forwarding of messages 
to other locations and other functions. Through the use of 
menus, parameter input screens and the like, client software 
at a user terminal permits the user greater control over 
receipt and display of messages. 

Other message handling features, methods and associated 
systems for practicing such methods, all within the spirit and 
scope of the present invention, will occur to those skilled in 
the art based on the foregoing descriptions. For example, 
though the preceding description has proceeded in terms of 
text messages, those skilled in the art will apply the present 
inventive teachings in communicating a variety of messages, 
including voice (or other audio), video (or other graphic) 
messages and in communicating mixed-mode messages or 
messages with a variety of attachments. 

What is claimed is: 

1. In a data network comprising a plurality of nodes, at 
least some of which nodes are connected to terminals, each 
terminal associated with a user, a method for communicating 
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between users in a plurality of simultaneous text chat 
conversations, each chat conversation comprising a selected 
plurality of said users (participants) to the exclusion of other 
non-participant users, the method comprising, separately for 
s each of said plurality of simultaneous text chat 
conversations, the steps of 

maintaining at a first set of said terminals a plurality of 
windows viewable by an associated user, each of said 
windows being associated with one of said chat 
to conversations, 

receiving at one of said first set of terminals a message 
comprising an originator ID and a conversation ID, and 
based on said message comprising said originator ID and 
said conversation ID, updating the conversation asso- 
15 ciated with a respective one of said windows at said one 
of said terminals. 

2. The method of claim 1 wherein said one of said first set 
of terminals is associated with a user having a first recipient 
name, said message received at said one of said first set of 

20 terminals including a list of recipients comprising said first 
recipient name, and said data network comprises at least one 
node performing the step of forwarding said message to said 
one of said first set of terminals. 

3. The method of claim 2 wherein said at least one node 
25 is a server node and wherein said server node performs said 

forwarding by performing the steps of 
forming a list of participants for each active chat conver- 
sation identified by an initiating user ID and a conver- 
sation ID, 

comparing the list of recipients in a received message 

with the stored list having the same initiating user ID 

and a conversation ID, and 
forwarding said received message to said first set of 
35 terminals when said list of recipients matches said 

stored list having the same initiating user ID and 

conversation ID. 

4. In a data network comprising at least one communi- 
cations server and a plurality of terminals, each said terminal 

40 associated with a user, each said terminal communicating 
with a respective communications server, a method for 
communicating between users in a plurality of simultaneous 
text chat conversations, each simultaneous text chat conver- 
sation comprising a selected plurality of said users 
45 (participants) to the exclusion of other non-participant users, 
the method comprising, separately for each of said plurality 
of simultaneous text chat conversations, the steps of 
receiving at a first communications server an initiating 
message from a initiating user terminal associated with 
5 q said first communications server, said initiating mes- 
sage comprising a list of initial recipients in a chat 
conversation and a chat identifier uniquely identifying 
a new chat session, 
establishing at said first communications server and each 
55 of said communications servers associated with at least 
one of said initial recipients a chat participant list for 
said new chat conversation, said chat participant list 
comprising said initial list of chat recipients and said 
initiating user, 

60 at each of said communications servers associated with a 
participant of a chat conversation, upon receipt of a 
subsequent message from a participant on said distri- 
bution list, said subsequent message comprising said 
chat identifier and a list of intended recipients of said 

65 message, 

adding to said participant list any intended recipient not 
on said participant list at each of said communications 
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servers associated with an intended recipient, and for- 
warding said subsequent message to users on said 
participant list. 

5. The method of claim 4 further comprising the steps of 
upon receipt at a second communications server of a 

message identified by a chat identifier and a list of 
intended recipients, said list of intended recipients 
including a user associated with said second commu- 
nications server, 
establishing a chat participant list at said second commu- 
nications server for said identified chat session, said 
chat participant list comprising all of said chat recipi- 
ents and the originator of said message. 

6. The method of claim 4 further comprising steps per- 
formed at a user terminal upon receipt of a message com- 
prising a chat identifier and a list of current participants, 

displaying in a display area uniquely associated with said 
chat identifier any content of said message and said list 
of current participants. 

7. The method of claim 4 wherein said at least one 
communications server comprises a plurality of intercon- 
nected servers, and wherein each of said interconnected 
servers maintains a chat participant list for said new chat 
conversation, said chat participant list initially comprising 
said initial list of chat recipients and said initiating user. 

8. In a data network comprising a plurality of nodes, at 
least some of which nodes are connected to terminals, each 
terminal associated with a user, a method for communicating 
between users in a plurality of chat conversations, each chat 
conversation comprising a selected plurality of said users 
(participants) to the exclusion of other non-participant users, 
the method comprising, separately for each of said plurality 
of chat conversations, the steps of 

maintaining at each of a first set of said terminals a first 
window viewable by an associated user, said window 
being associated with a first of said chat conversations, 

receiving at each of said first set of terminals first 
sequences of messages, each comprising a conversation 
initiator ID and a conversation ID for said first chat 
conversation, 

based on said first sequences of messages, updating the 
status of said first window at each of said first set of 
terminals, 

maintaining at each of at least a second set of said 
terminals a respective at least a second window view- 
able by an associated user, said at least a second 
windows being associated with respective ones of said 
chat conversations, 

receiving at each of said at least a second set of terminals 
respective sequences of messages, each comprising a 
conversation initiator ID and a conversation ID for a 
respective chat conversation, 

based on each of said at least a second sequences of 
messages, updating the status of said respective one of 
said at least a second window at each of said at least a 
second set of terminals. 

9. The method of claim 8 wherein said first set of 
terminals and said at least a second set of terminals are not 
mutually exclusive, whereby at least some of said terminals 
maintain a plurality of windows, each window being asso- 
ciated with a respective one of said chat conversations. 

10. The method of claim 8 wherein at least one of said 
nodes is a server node, said at least one server node(s) 
performing the steps of 

receiving messages from associated terminals, and 
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forwarding said received messages in accordance with a 
list of recipients included in said messages. 

11. The method of claim 10 further comprising at said 
server the steps of comparing the list of recipients in a 

5 received message with a stored list associated with the 
conversation initiator ID and conversation ID for said 
received message, and 

forwarding said received message to said list of recipients 
in said received message when said list of recipients 
10 matches said stored list, 

12. In a data network comprising a plurality of nodes, at 
least some of which nodes connected to terminals, each 
terminal associated with a user, a method for are commu- 
nicating between users in a plurality of chat conversations, 

15 each chat conversation comprising a selected plurality of 
said users (participants) to the exclusion of other non- 
participant users, the method comprising, separately for each 
of said plurality of chat conversations, the steps of 

maintaining at each of a first set of said terminals a first 
20 window viewable by an associated user, said window 
being associated with a first of said chat conversations, 
receiving at each of said first set of terminals first 
sequences of messages, each comprising a conversation 
25 initiator ID and a conversation ID for said first chat 
conversation, 

based on said first sequences of messages, updating the 
status of said first window at each of said first set of 
terminals, 

30 maintaining at each of at least a second set of said 
terminals a respective at least a second window view- 
able by an associated user, said at least a second 
windows being associated with respective ones of said 
chat conversations, 

35 receiving at each of said at least a second set of terminals 
respective sequences of messages, each comprising a 
conversation initiator ID and a conversation ID for a 
respective chat conversation, 
based on each of said at least a second sequences of 

40 messages, updating the status of said respective one of 
said at least a second window at each of said at least a 
second set of terminals. 

13. A communications server supporting chat conversa- 
tions among a plurality of user terminals comprising 

45 means for receiving an initiating message from one of 
said user terminals for each of said chat conversations, 
said initiating message comprising a conversation ID, a 
conversation initiator ID and an initial list of recipients, 
means uniquely associated with each combination of said 

50 conversation ID and said conversation initiator ID for 
storing said respective initial list of recipients, 
means for receiving chat messages from a plurality of user 
terminals, each such message comprising a conversa- 

55 tion ID, a conversation initiator ID and a list of 
recipients, 

means for comparing the list of recipients in each message 
having a particular combination of conversation ID and 
conversation initiator ID with the stored list of recipi- 
60 ents associated with said particular combination, and 

means for forwarding said message having said particular 
combination to said list of recipients in said message 
when said list of recipients matches those stored in 
association with said particular combination. 
65 14. The server of claim 13 further comprising 

means for replacing said stored fist associated with said 
particular combination with said recipient list recipient 
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list in said message having said particular combination 
whenever said recipient list in said message having said 
particular combination is a proper subset of said stored 
list. 

15. A user terminal for use in a data communications 5 
system supporting a plurality of simultaneous text chat 
conversations among a plurality of user terminals, each chat 
conversation being conducted among a selected plurality of 
users (participants) at respective user terminals to the exclu- 
sion of other non-participant users, said terminal comprising 10 

means for displaying a plurality of text chat conversation 
windows, 
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means for receiving messages, each message comprising 
at least a chat conversation ID and a conversation 
initiator ID, the combination of said chat conversation 
ID and conversation initiator ID being uniquely asso- 
ciated with one of said plurality of windows, said 
messages optionally containing control or user conver- 
sation information, 
means for updating respective ones of said windows 
based on messages having uniquely associated combi- 
nations of said chat conversation IDs and conversation 
initiator IDs. 

***** 
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